Conventionally, Conventionally, a plurality of communication devices each having a communication function are mutually connected through a network so as to architect various systems. As an example, a system so-called “electronic commerce system” has been architected so that a computer such as a PC (personal computer) or a like functioning as a client terminal sends an order of a product and a server computer connecting to the client terminal through the Internet accepts that order. In addition, a system is proposed in that a function of the client terminal or the server computer is implemented to various electronic apparatuses, and the electronic apparatuses are connected to each other through a network, to conduct a remote management of the electronic apparatuses by intercommunications.
In order to architect this system, it is important to check whether a communication partner is a proper partner or whether information sent from the communication partner is tampered with when communicating with the communication partner. In addition, particularly in the Internet, the information generally passes through irrelevant computers toward the communication partner. When confidential information is transmitted, it is necessary to protect contents of the confidential information. Then, as a communication protocol corresponding to this requirement, for example, a protocol called an SSL (Secure Socket Layer) has been developed, and widely used. In communication using this protocol, it is possible to prevent falsification and interception by encrypting the confidential information in addition to combining a public key encryption method and a shared key encryption method and authenticating the communication partner. Also, at a side of the communication partner, it is possible to authenticate a device as a communication originator requesting communication.
Japanese Laid-Open Patent Applications No. 2002-353959 and No. 2002-251492 disclose technologies related to an authentication using the SSL and the public key encryption.
In the following, a communication procedure in a case of conducting a mutual authentication in accordance with the SSL will be described while focusing on a portion of the authentication process. FIG. 1 is a diagram showing a flowchart conducted by each of communication devices A and B when the communication devices A and B conduct a mutual authentication in accordance with the SSL, accompanying with information used in each process.
As shown in FIG. 1, when the mutual authentication is conducted in accordance with the SSL, it is necessary for the communication devices A and B to store a combination of a root key certificate and a private key and a combination of the root key certificate and a public key certificate, respectively. The private key is a key which a CA (Certificate Authority) issues for each of the communication devices A and B. The public key certificate is a digital certificate in that the CA additionally provides a digital signature to the public key corresponding to the private key. Also, the root key certificate is a digital certificate in which the CA additionally provides the digital signature to a root key corresponding to a root private key used for the digital signature.
FIG. 2A and FIG. 2B show their relationships.
As shown in FIG. 2A1, a public key A includes a key body for decrypting a document which is encrypted by using a private key A, and bibliography information including information concerning an issuer (CA) of the public key, a valid term, and a like. In order to show that the key body and the bibliography information are not tampered, the CA encrypts a hash value obtained by conducting a hash process with respect to the public key A, by using the root private key, and additionally provides the hash valued being encrypted as digital signature to the public key of a client. Also, in this case, identification information of the root private key used for the digital signature is additionally provided to the bibliography information of the public key A as signature key information. Accordingly, the public key certificate to which this digital signature is provided is a public key certificate A.
In a case of using the public key certificate A for the authentication process, the digital signature included in the public key certificate A is decoded by using the key body of the root key as the public key corresponding to the root public key. When this decryption is normally conducted, it is recognized that the digital signature is surely provided by the CA. Moreover, if a hash value obtained by conducting the hash process with respect to the portion of the public key A is identical to a hash value obtained from the decryption, it is recognized that the key itself is not suffering from compromised and tampered.
Also, if received data is normally decrypted by using the public key A, it is recognized that the received data is surely sent from an owner of the private key A.
In order to conduct the authentication process, it is necessary to store the root key beforehand. As shown in FIG. 2B, the root key is also stored as the root key certificate to which the CA provides the digital signature. In this case, the root key certificate is a self-signature format in which the digital signature can be decrypted with the public key included in the root key certificate itself. When the root key is used, the digital signature is decrypted by using the key body included in the root key certificate, and the root key is compared with the hash value obtained by the hash process. If the root key is identical to the hash value, it can be confirmed that the root key is not compromised.
Each of the flowcharts shown in FIG. 1 will be described. It should be noted that arrows between two flowcharts denote data transmission. A sender side conducts a transmission process in a step at a start point of the arrow, and a receiver side conducts a process in a step at an end point of the arrow when the receiver side receives data from the sender side. Moreover, if a process in each step is not normally ended, a response showing an authentication failure is returned to the communication partner and the process is terminated in that step. When the authentication failure is received from the communication partner, or when the process is timed out, similarly, the response showing an authentication failure is returned to the communication partner and the process is terminated in that step.
In this case, the communication device A sends a request to the communication device B in order to communicate therewith. In a case of conducting the communication request, a CPU of the communication device A starts a process in accordance with the flowchart shown at a left side in the FIG. 1 by executing a predetermined control program. Then, the communication device A sends a communication request to the communication device B in step S211.
On the other hand, when a CPU of the communication device B receives the communication request, the communication device B starts a process in accordance with the flowchart shown at a right side in FIG. 1 by executing a predetermined control program. In step S221, a first random number is generated, and is encrypted by using the private key B. Then, in step S222, the first random number being encrypted and the public key certificate B are sent to the communication device A.
At the communication device A, when the first random number being encrypted and the public key certificate B are received, validity of the public key certificate B is confirmed by using the root key certificate in step S212.
When the validity is confirmed, the first random number is decrypted by using the public key B included in the public key certificate B received from the communication device B in step S213. If the first random number is successfully decrypted, it can be confirmed that the first random number is surely received from an issuance subject of the public key certificate B.
After that, a second random number other than the first random number and a seed of a shared key are generated in step S214. For example, the seed of the shared key can be created based on data exchanged with the communication device B during the intercommunication. Then, the second random number is encrypted by using the private key A and the seed of the shared key is encrypted by using the public key B in step S215. In step S216, the second random number and the seed of the shared key are sent with the public key certificate A to the communication device B. The seed of the shared key is encrypted, so that any device other than the communication partner cannot recognize the seed of the shared key.
Moreover, in step S217 following to the step S216, a shared key is generated from the seed of the shared key generated in the step S214, in order to use to encrypt for further communications.
At the communication device B, when data sent from the communication device A in step S216 is received, the validity of the public key certificate A is confirmed by using the root key certificate in step S223. When the validity is confirmed, the second random number is decrypted by using the public key A included in the public key certificate A received from the communication device A in step Ξ224. When the second random number is successfully decrypted, it can be confirmed that the second random number is surely received from an issuance subject of the public key certificate A.
After that, in step S225, the seed of the shared key is decrypted by using the private key B. By processes previously conducted, the communication device A and the communication device B share the seed of the shared key with each other. Also, the seed of the shared key cannot be known to any device other than the communication device A which generated the seed of the shared key and the communication device B which possesses the private key B. When the above conducted processes are successful, the shared key is generated from the seed of the shared key decrypted and obtained in step S226, in order to use for further communications.
Subsequently, when a process in the step S217 at the communication device A and a process in the step S226 at the communication device B are completed, the communication devices A and B mutually confirm the successful authentications and an encryption method for the further communications. Accordingly, the communication devices A and B start to communicate with each other in accordance with the encryption method by using the shared key generated at each side of the communication devices A and B, and terminate the processes concerning the authentication. While the communication devices A and B mutually confirm the successful authentications and an encryption method for the further communications, the communication devices A and B send a response showing the successful authentication. By the above-described process, the communication devices A and B establish communication with each other. In the following communications, the communication devices A and B use the shared key generated in the step S217 and S226, respectively, and can communicate with each other by encrypting data in the encryption method using the shared key.
By conducting the above-described processes, the communication devices A and B authenticate each other first, and then share the shared key so as to establish a path to securely communicate with each other.
In a case of applying a one-way authentication, for example, if only the communication device B may authenticate the communication device A, it is possible to omit the encryption of the first random number and the transmission of the first random number-in the authentication process shown in FIG. 1. In this case, in order to securely send the seed of the shared key from the communication device A to the communication device B, an encryption using the public key B of the communication device B may be conducted, but it is not necessary to confirm the validity of the digital signature attached to the public key B. Accordingly, the authentication in this case can be simplified as shown in FIG. 3. That is, the steps S212 and S213 at the communication device A are not required, and the step S221 at the communication device B is not required. Also, other processes can be partially simplified.
In the above-described authentication process, contents being encrypted with the public key are decrypted by only a device having the private key corresponding to the public key, and contents being encrypted with the private key are decrypted with only the public key corresponding to the private key. Due to this feature, the communication partner authenticates that the public key certificate describes the device as an issuance destination (or the public key certificate describes a user as the issuance destination).
Japanese Laid-Open Patent Applications No. 2003-348068 (paragraph 0004) and No. 2002-190796 disclose technologies related to a management of the public key used for the authentication process.
The Japanese Laid-Open Patent Application No. 2003-348068 discloses to implement a key registration device on a network and to manage a public key, so as to reduce a workload of a user.
The Japanese Laid-Open Patent Application No. 2002-190796 discloses to automatically register necessary public keys only to a public key database of an electronic mail apparatus and to automatically manage so as to maintain only valid public keys in a case of using a public key encryption in order to encrypt an electronic mail.
However, in a public key encryption method, disadvantageously, the private key can be obtained from the public key if spending sufficient time depending on a key length. Accordingly, if the private key is recognized, a third party can pretend to be an owner of the private key. Thus, reliability of the authentication and security of the communication cannot be maintained. Thus, the number of users, who applies a security policy of providing a validated date and update a key set at predetermined period as described above, increases. Therefore, for example, in a case of providing the remote management system using the mutual authentication as described above, it is required to guarantee to a customer that the key can be updated.
As a method for distributing a new public key certificate to update to a communication device, which is to be authenticated by using the public key certificate, the CA issues a new public key certificate and a new private key to the communication device before the validated date of the public key certificate in use is expired, and the CA or a management apparatus taking the place of the CA send and set the root key certificate in addition to the public key certificate and the private key to a device of an update subject through a communication path using the SSL, which is established by using the public key certificate in use.
In this manner, the communication device can automatically update the public key certificate and the like used for the authentication before the validated date is expired. Therefore, without any trouble to the user of the communication device, it is possible to maintain the communication device to be in a state possible for the authentication. Moreover, in a case of conducting a transmission through the Internet, it is possible to conduct the transmission of the public key certificate and the like while maintaining the communication path to be secured.
However, even though the communication path is maintained to be secured by using the SSL, in a case of communication through the Internet, since information may be transferred through several servers, a possibility of spying and falsifying of the information to transfer cannot be completely eliminated. If the private key is spied, spoofing can be possible. Thus, it is desired to eliminate a risk such as spoofing even if the risk has less possibility.
However, in this case, if a means for acquiring an emergency communication path between the communication device and the CA or the management apparatus is provided to the communication device, it is possible to obtain a new public key certificate to establish a regular communication path through the emergency communication path.-As this emergency communication path, for example, a public key certificate having longer validated date, a private key corresponding to the public key certificate, and a root key certificate may be stored in devices produced by the vendor and shared with each other, and the communication path using the SSL can be established between each device and the CA or the management apparatus.
Regarding this technology, the applicant of the present invention filed Japanese Patent Application No. 2003-341329, which has not been published at the present time.
This emergency communication path is not normally used. However, even if a regular communication path has something wrong, this emergency communication path is required to be secured. Thus, it is difficult to conduct an authentication process rigidly similar to the regular communication path. For example, in a case of storing the shared public key certificate to each device as described above, since the identification information of each device cannot be described in the public key certificate. As a result, it is not possible to refer to the identification information of each device when the authentication process is conducted by using SSL. Thus, the CA or the management apparatus causes the communication device to send the identification information after the communication path is established, relies on the identification information, and sends an update public key certificate and a like to the communication device.
Accordingly, regarding the emergency communication path, there is a problem in that it is relatively easy to disguise to be a proper communication device to acquire the update public key certificate. Therefore, even in a case of using the emergency communication path, that is, even in a case in that the regular communication path is not used, it is desired to effectively prevent from spoofing.
Regarding this point, the above-described patent documents do not disclose an update of the public key certificate in a sate in that the pubic key certificate being regularly used cannot be used.
Moreover, for reasons of production equipment and a like, like the emergency public key certificate, it is necessary to set the shared public key certificate for each device with respect to the public key certificate being regularly used. In this case, similar to a case of using the emergency communication path, even if the public key certificate being regularly used is updated within a valid term, it is desired to effectively prevent from spoofing.